home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / e / misc.save / 000326_sms.antinode@gmail.com_Sat Mar 13 11:18:46 2010.msg < prev    next >
Internet Message Format  |  2011-07-03  |  5KB
  1. Path: reader1.panix.com!panix!usenet.stanford.edu!postnews.google.com!g28g2000yqh.googlegroups.com!not-for-mail
  2. From: Steven Schweda <sms.antinode@gmail.com>
  3. Newsgroups: comp.protocols.kermit.misc
  4. Subject: Re: C-Kermit 9.0 for VAX?
  5. Date: Fri, 12 Mar 2010 19:40:29 -0800 (PST)
  6. Organization: http://groups.google.com
  7. Lines: 76
  8. Message-ID: <35c371b6-5d75-40c2-89a3-00b977ee9b88@g28g2000yqh.googlegroups.com>
  9. References: <slrnhn34mm.em3.fdc@panix2.panix.com> <cd3c4f24-9503-451d-a2a6-a82aca4152ad@x22g2000yqx.googlegroups.com> 
  10.     <slrnhn653a.shk.fdc@panix1.panix.com> <b024c26a-a8ec-4ac2-89ad-b6662d8d58bd@a18g2000yqc.googlegroups.com> 
  11.     <slrnhpl8gu.1ob.fdc@panix3.panix.com>
  12. NNTP-Posting-Host: 209.98.249.184
  13. Mime-Version: 1.0
  14. Content-Type: text/plain; charset=ISO-8859-1
  15. X-Trace: posting.google.com 1268451629 32344 127.0.0.1 (13 Mar 2010 03:40:29 GMT)
  16. X-Complaints-To: groups-abuse@google.com
  17. NNTP-Posting-Date: Sat, 13 Mar 2010 03:40:29 +0000 (UTC)
  18. Complaints-To: groups-abuse@google.com
  19. Injection-Info: g28g2000yqh.googlegroups.com; posting-host=209.98.249.184; 
  20.     posting-account=OjKUgAkAAAAXAqdVEKd-Gc8RltEUx3Xq
  21. User-Agent: G2/1.0
  22. X-HTTP-UserAgent: Mozilla/5.0 (X11; U; OpenVMS COMPAQ_Professional_Workstation; 
  23.     en-US; rv:1.8.1.17) Gecko/20081029 SeaMonkey/1.1.12,gzip(gfe),gzip(gfe)
  24. Xref: panix comp.protocols.kermit.misc:15928
  25.  
  26. Frank da Cruz wrote:
  27.  
  28. > : You working on that 64-bit math package for 32-bit systems?
  29. > :
  30. > I did it already for Unix.  I just use off_t instead of int.
  31. > If a 32-bit system has off_t defined as a 64-bit signed int,
  32. > poof, you have 64-bit arithmetic.
  33.  
  34.    Sadly, on VAX, off_t is 32 bits, and I'm unaware of any
  35. 64-bit integer type.  Normally I wouldn't care, but someone
  36. recently reminded me that Kermit on VMS doesn't use the C RTL
  37. for file I/O, which did suggest that there might be hope for
  38. proper large-file behavior (even) on VAX.  However, if all the
  39. size/offset code is written assuming that off_t will do the
  40. job, then there's probably little hope of finding a practical
  41. way to make it work on VAX.
  42.  
  43.    On the bright side, the builder's P1 "F" option leads to
  44. defining the C macros _LARGEFILE_SOURCE and _LARGEFILE, and
  45. they do seem to persuade a semi-recent non-VAX system (VMS >=
  46. V7.2, DEC C > V5.2 (actually, "__DECC_VER > 50230003")) to use
  47. a 64-bit off_t and CK_OFF_T.
  48.  
  49.    Running a quick "ftp /binary get" on that 5GB file on an
  50. Alpha, I don't get the same unrealistic "File Size: 905019392"
  51. which I did on the VAX, but the "File Size: <blank>" (with the
  52. matching "Estimated Time Left: (unknown)") suggests that
  53. someone somewhere still could use some work.  I'll try to keep
  54. an eye open for negative numbers, and let you know.
  55.  
  56.    Got past "Bytes So Far: 2147483647" without going negative.
  57. What could go wrong now?
  58.  
  59.    Also on the missing features list, I just noticed (again?
  60. (Who can remember?)) that the code in ckvfio.c still uses
  61. "struct NAM" everywhere, which means that ODS5 extended file
  62. names can't be used.  The code in (my) ckvrtl.c shows one way
  63. to allow the use of the new(er) NAML where it exists.  I'm not
  64. sure how many Kermit buffers will overflow if we start using a
  65. maximum name length of NAML$C_MAXRSS (4095) instead of the old
  66. NAM$C_MAXRSS (255).  Other code can need revision because
  67. formerly special characters (like, say, ":", "[", or " ") can
  68. now appear in file names (with "^" prefixes).  Everything's
  69. complicated (and getting worse all the time).  I can try to
  70. put in the basic NAML support, but I would not bet on my doing
  71. all the testing needed to see if everything really works right
  72. on exotic extended file names.
  73.  
  74.    Speaking of maximum name length, nowadays, on VMS,
  75. CKMAXPATH is being set to PATH_MAX (256), which is entirely
  76. unrealistic for ODS5.  Listing extract:
  77.  
  78. [...]
  79.  I1       12361 #ifndef CKMAXPATH
  80.  I1    X  12362 #ifdef MAXPATHLEN                       /* (it
  81. probably isn't) */
  82.  I1    X  12363 #define CKMAXPATH MAXPATHLEN
  83.  I1    X  12364 #else
  84.  I1       12365 #ifdef PATH_MAX                         /* POSIX */
  85.  I1       12366 #define CKMAXPATH PATH_MAX
  86.  I1    X  12367 #else
  87. [...]
  88.  I1    X  12377 #ifdef VMS
  89.  I1    X  12378 #define CKMAXPATH 675                   /* (derivation
  90. is complicated...) */
  91.  I1    X  12379 #else
  92. [...]
  93.           35585 static char nambuf[CKMAXPATH];          /* maximum
  94. size of a file spec */
  95.        E                           256
  96.           35586 static char cwdbuf[NAM$C_MAXRSS];
  97.        E                           255
  98. [...]
  99.  
  100. I can't help wondering whence came that "675" value, but it's
  101. not getting used, so it may not matter much.